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PREFACE 



This manual provides the instructions necessary to use Intel's Program Management 
Tools (PMTs). These tools minimize the administrative overhead of managing a 
software development project. PMTs work with the existing operating systems and 
software tools to enable you to control, automate, and examine the evolution of 
software projects. PMTs are essential on large multi-programmer development efforts 
and extremely valuable on smaller software projects. PMTs automate the tedious 
administrative functions associated with software development. 

This manual is intended for both systems designers and application programmers. It 
describes tools that aid in handling the complexities of program development and 
maintenance for projects ranging from a single programmer with a half-dozen modules 
to large, multi-programmer projects with hundreds of modules. 

Chapter 1, "Getting Started with PMTs," presents an overview, describes the 
environment, and summarizes a software methodology that fully uses the tools. 

Chapter 2, "Program Construction (MAKE)," contains the instructions necessary to 
invoke and execute the MAKE program that creates the generation of a new software 
release. 

Chapter 3, "Software Version Control System (SVCS)," contains the instructions 
necessary to invoke and execute the SVCS program that provides control over software 
changes and versions. 

Appendix A, "Summary of MAKE/SVCS Commands and Prompts," provides an 
easily accessed list of commands and prompts. 

Appendix B, "Additional Information for the Series III User," provides more 
information about using PMTs on a Series III development system. 



Related Publications 

For further information on the Series III, refer to the following publications: 

Intellec Series HI Microcomputer Development System Product Overview, 

121575 

Intellec Series III Microcomputer Development System Console Operating 
Instructions, 121609 

Intellec Series III Microcomputer Development System Programmer's 
Reference Manual, 121618 

ISIS-II User's Guide, 9800306 

ISIS-II Software Toolbox User's Guide, 121727 

Winchester Peripheral Chassis I SIS -II (W) Supplement, 121899 

For more information on the NDS-II system, refer to the following manuals: 
NDS-II ISIS-III(N) User's Guide, 121765 
NDS-II Network Development System Overview, 121761 
NDS-II System Generation Instructions, 121763 
NDS-II Network Resource Manager Operating Instructions, 121883 



Notational Conventions 

This manual adheres to the following conventions in describing the syntax of the 
commands accepted by MAKE and SVCS: 



UPPERCASE 

italic 

directory-name 

filename 
pathname 

system-id 

Vx.y 

[ ] 

{ y 



punctuation 



Characters shown in uppercase must be entered in the order 
shown. You may enter the characters in uppercase or lower- 
case. 

Italic indicates a meta symbol that may be replaced with an 
item that fulfills the rules for that symbol. The actual symbol 
may be any of the following: 

Is that portion of a pathname that acts as a file locator by 
identifying the device and/or directory containing the 
filename. 

Is a valid name for the part of a pathname that names a file. 

Is a valid designation for a file; in its entirety, it consists of a 
directory and a filename. 

Is a generic label placed on sample listings where an 
operating system-dependent name would actually be printed. 

Is a generic label placed on sample listings where the version 
number of the product that produced the listing would 
actually be printed. 

Brackets indicate optional arguments or parameters. 

One and only one of the enclosed entries must be selected 
unless the field is also surrounded by brackets, in which case 
it is optional. 

At least one oT the enclosed items must be selected unless the 
field is also surrounded by brackets, in which case it is 
optional. The items may be used in any order unless other- 
wise noted. 



The vertical bar separates options within brackets [ 
braces i > . 



or 



Ellipses indicate that the preceding argument or parameter 
may be repeated. 

The preceding item may be repeated, but each repetition must 
be separated by a comma. 

Punctuation other than ellipses, braces, and brackets must be 
entered as shown. For example, the punctuation shown in the 
following command must be entered: 

SUBMIT PLM86CPR0GA , SRC , *9 SEPT 81') 

In interactive examples, user input lines are printed in white 
on black to differentiate them from system output. 



< c r > 



Indicates a carriage return. 
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CHAPTER 1 
GETTING STARTED WITH PMTs 



What are Intel's Program Management Tools? 

PMTs are a set of software tools designed to simplify and reduce the manual effort 
required to manage the software development process. PMTs essentially: 

• Act as programmable secretaries and eliminate the manual administrative tasks 
of tracking program changes and managing module variants 

• Decrease overhead associated with software management 

• Control, automate, and examine the release of a product 

PMT Components 

The PMTs are independent programs that may be used either separately or together. 
Two such programs presently exist: MAKE and the Software Version Control System 
(SVCS). 

The MAKE Program 

MAKE is a tool that creates software generation procedures for constructing new 
releases of software. Without MAKE, new releases of a software system are created 
in one of two ways: One way is to perform the generation from the ground up, 
compiling all source modules and linking all object modules using a submit file. This 
method wastes considerable time on unnecessary compilations of modules that were 
unchanged since the last generation. The second (and more common) approach is to 
keep track of the modules that have been modified, and create a new and different 
generation procedure for each release. This method saves compilation time, but 
involves considerable administrative overhead, thereby compounding the chances of 
human error. 

With the MAKE facility, you can specify how the system is constructed and 
automatically generate the appropriate minimal submit file. This reduces both unnec- 
essary compiles and links, and the manual effort required to track changed modules. 

MAKE provides you with the confidence that the program is constructed with the 
latest source and object code without unnecessary processing. 

The SVCS Program 

SVCS is a tool that simplifies many of the module housekeeping tasks. SVCS provides 
a means of tracking changes to program source code, maintaining variants of the 
source and object modules for a program, and recording access to these modules in a 
multi-programmer environment. 

Because SVCS tracks source changes, you can print out the change history of a source 
module showing the author and time of each creation and change. 

Another important use of SVCS is to track different variants of a module. These 
variants may represent different prototype releases or customized variants of software 
for different end products. SVCS tracks source modules, include files, object modules, 
link and load modules, and documentation (specifications, design documents, user 
manuals). 
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Incorporating MAKE and SVCS into existing software methodology is straightfor- 
ward. These programs are designed to work with the existing operating system and 
software utilities (editors, compilers, utilities), and require about the same learning 
effort as the system functions (COPY, RENAME, ACCESS). 



What Environment is Needed? 

PMTs require an 8086/8088-based development system with 96K of user memory 
(in addition to space used by the operating system). 

PMTs are ideal in a networked environment, such as NDS-II (using ISIS-III(N)) 
where multi-programmer software control is essential; however, they are just as useful 
on standalone winchester-based systems (using ISIS-II(W)). 



Learning to Use MAKE and SVCS 

This section shows you a very basic application of MAKE and SVCS. It has been 
designed to familiarize you with the most elementary commands and methodology. 
It further illustrates how easily MAKE and SVCS can be incorporated into an 
existing software project. 

To develop a basic learning environment, we describe a software development project 
where two programmers are working on one part (e.g., an I/O subsystem) of a larger 
multi-programmer project. 

Some of the common administrative headaches we can eliminate for you by using 
PMTs are 

• Source contention — both programmers may attempt to make changes to a single 
source module simultaneously. 

• Variations — several versions of a given module may be active in different proto- 
types, during various phases of debugging. A stable version may be used when 
debugging the whole system; a less stable but more functional version may be 
debugged independently. 

• Generation — the latest version of some modules may need to go into each new 
generation. Past versions of other modules may be needed also. 

MAKE and SVCS provide solutions to these development problems. MAKE 
automatically handles the software generation process; SVCS provides control to the 
edit/translate/debug process. SVCS is also responsible for the control of the 
variations of each module and for the control of the various pieces of the system. 

Typically, these tools can be used in the development cycle in the following way: 

1 . A project data base is set up, using SVCS. SVCS provides administrative functions 
to install source and object modules, define variants to modules, and define the 
composition of modules. 

2. A MAKE file is created to describe how the different pieces of the software 
system fit together. 

3. Once the data base and MAKE file are set up, administrative changes are usually 
minimal. Day-to-day use of SVCS will be to check out and return modules, just 
as you would a library book. 

To make changes to a module, it is checked out with the SVCS GET command 
with WRITE privilege. The file is then edited, using ALTER, CREDIT, or 
another text editor. 
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4. After one or more modules are checked out and edited, a new version or proto- 
type is generated. This is done with one MAKE and (usually) one submit 
command. 

5. The new source and objects may be returned to the data base, using an SVCS 
PUT command. (This process does not have to occur at this point since additional 
changes and generations can take place.) 

6. The new version is debugged and tested, using PSCOPE, ICE, or another debug- 
ger. It is probable that several edit/debug'cycles will take place before returning 
the changed modules to the SVCS data base. 

7. When the modules are returned, SVCS automatically updates the change history 
of the modules, recording who made the changes, what changed, when the changes 
were made, and why. 

8. The SVCS GET, edit, MAKE, debug, SVCS PUT cycle is repeated, with GETs 
and PUTs being performed for each change, or perhaps just once a day. This 
cycle depends on how many different programmers want to make modifications 
to a given source module. 

For simplicity, assume that the subsystem under development (lO.LNK) contains 
four modules (READ. SRC, WRITE.SRC, DATA.SRC, UTIL.SRC) that are 
compiled and linked to form lO.LNK. 

The subsystem module lO.LNK is dependent on (constructed from) four source files 
(READ.SRC, WRITE.SRC, DATA.SRC, UTIL.SRC) that are in turn dependent 
on their corresponding object files (READ. OBJ, WRITE.OBJ, DATA.OBJ, 
UTIL.OBJ). This dependency is represented in figure 1-1 and specified by the user 
in a MAKE file (e.g., lO.MKE). It is essential that the MAKE file be accurate and 
complete to perform the correct generation. Figure 1-2 is an example of a MAKE 
file for lO.LNK. Figure 1-3 shows some source SVCS and MAKE invocations 
corresponding to the usage described previously. 



lO.LNK 
SUBSYSTEM 



( READ.OBJ ) f WRITE.OBJ ) ( DATA.OBJ ) ( UTIL.OBJ j 



DEPENDENCY 
NODES 






I UTIL.SRC 1 



( ^ = OBJECT FILE 

C^ = SOURCE FILE 



Figure 1-1. MAKE Dependency Graph 
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SERIES-III MAKK, VI. (^ (^7/30/32 

MAKE IMVOKKD BY: rFliMAKE.^'^ :F1:I0.MKE PRINT ( : Fl : I . LST^ 
S'JBMIT FILE: :Fl:IO.CSn 

1 
2 

3 SIF lO.LNK > READ. ORJ, WRITE. OBJ, nATA. OBJ, UTIL. OBJ THEN 

4 LINKS'^ READ. ORJ, WRITE. OBJ, DATA. OBJ, UTIL. OBJ TO lO.LNK 

5 SEND 
(^ 

7 SIF READ. OBJ > READ. SRC THEN 

8 PLM«'^ READ. SRC 

9 SEND 
10 

11 $IF WRITE. OBJ > WRITE. SRC THEN 

12 PLMR«; WRITE. SRC 

13 SEND 
14 

15 SIF DATA. OBJ > DATA. SRC THEN 
1<S PLMR<^ DATA. SRC 
17 SEND 

la 

19 SIF UTIL.OBJ > UTIL.SRC THEN 

20 PLMR«5 UTIL.SRC 

21 SEND 
22 



DEPENDENCY TREE 

1 lO.LNK 

2 READ. OBJ 

3 READ. SRC 

2 WRITE. OB J 

3 WRITE. SRC 

2 DATA. OBJ 

3 DATA. SRC 

2 UTIL.OBJ 

3 UTIL.SRC 



MAKE FILE SUMMARY 

NUMBER OF LINES = 22 
NUMBER OF ERRORS = 



Figure 1-2. Sample MAKE File 



RUN SVCS GET : F 1 : I . D B ( R E A D ) TO iFSiREAD.SRC WRITE IDCJNS) 
; a "get" with write permission 

RUN ALTER : F5 : READ. SRC 

; make changes to source file 

RUN SVCS PUT :F1:I0.DBCREAD) FROM :F5!gEAD.SRC ID(JNS) 
; put the changed module back 

RUN MAKE : F 1 : I . DB. MKE 

; this creates the generation procedure 

RUN SUBMIT : F 1 : 10 .DB. CSD 

; submit the generation procedure created by MAKE 

RUN PSCGPE 

; debug the load module 

Figure 1-3. A Sample of SVCS and MAKE 
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Incorporating MAKE and SVCS into an Existing Project 

Changing development methodologies during a project has some inherent risks. Most 
project leaders will choose not to abandon current conventions when a release date is 
near. However, administrative headaches compound as the release data approaches; 
MAKE and SVCS provide the relief needed at that stage of a project. 

Some guidelines for including MAKE and SVCS into an ongoing project are listed 
in this section. These guidelines should help you measure both the effort required and 
the associated risk. 

1. Converting submit files to MAKE files. The most common form of software 
generation involves a prolific use of submit files. To alleviate the problem of 
unnecessary compiles and links, submit files are usually edited for every new 
generation. This is the effort that MAKE automates. 

To adopt MAKE in the generation process, the complete set of submit files should 
be converted to input files for MAKE. This means learning the command language 
(Chapter 2) and converting the procedures. If the submit files were just a series 
of compiles and links, learning the command language and converting the proce- 
dures are very straightforward (use figure 1-2 as a reference). If the submit files 
contain ISIS commands (COPY, DELETE, etc.) or ISIS Toolbox commands 
(IF, THEN, GOTO, etc.), more thought may be required. (A MAKE file can 
exploit some powerful macros; they just have to be learned.) 

The important point, however, is that once this MAKE file is created, you are 
finished with it. A MAKE file has to change only if the structure of the whole 
system changes. Test the MAKE file (with the GEN ALL option) to see if it is 
generating the correct submit file. 

2. Setting up the SVCS data base. Installing source, object, include, link, and load 
modules into an SVCS data base is repetitive work. It is quite straightforward 
using the SVCS ADMIN commands (Chapter 3), but for a large system the 
process may be lengthy. You should automate it by using a submit file. It should 
take only a few hours to learn the syntax and create all the SVCS ADMIN 
commands. The actual installation, if automated, will take about twice as long 
as it would to copy each source and object from one file to another. (All SVCS 
commands may be thought of as intelligent copy commands.) 

3. Day-to-day use. Once the overhead of setting up the SVCS data base and creat- 
ing the MAKE file is done, the PMTs begin lowering the administrative burden. 

For software generation, the MAKE, SUBMIT sequence should replace the 
editing of submit files, the tracking down of latest versions, and the effort to 
determine what modules have changed. 

For making program changes, the SVCS GET, ALTER, SVCS PUT sequence 
will replace the uncontrolled editing, copying, archiving, and disk-labeling of 
software modules. This sequence will also reduce the problems caused by lack of 
control, such as deleting the wrong versions, debugging the wrong versions, and 
making simultaneous changes to modules. 

Learning to use MAKE (day-to-day) is like using SUBMIT — the command is 
very short, the options few. Learning how to use SVCS in a controlled manner is 
slightly more complicated (due to its flexibility) and represents the only ongoing 
investment in getting a large project converted to a new approach. To reduce the 
confrontation of SVCS, SVCS prompts the user for any required command option 
left off, rather than reporting an error. Learning SVCS is no more difficult than 
learning the collection of utilities it replaces: COPY, ATTRIB, DELETE, etc. 

The next sections provide a tutorial on getting started with MAKE and SVCS; they 
cover the important and most frequently used commands and options. Chapters 2 and 
3 serve as reference material for the whole command set. 
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Starting with i^/IAKE 

MAKE takes an input file and generates an output (submit) file and a listing. 

This section illustrates how you would construct a MAKE input file and invoke the 
MAKE command. 



Invoking MAKE 

To activate MAKE processing, type: 



MAKE make- 



The following message is then displayed: 
system-id MAKE, Vx.y 



Constructing a l\/IAKE File 

The file to be constructed (usually a load module) is referred to as the target. Its 
constituent files are known as dependency files. A MAKE file consists of a series of 
dependency nodes. 

A dollar sign must appear as the first non-blank (or tab) character on a MAKE 
command line. 

The format of each dependency node in a MAKE file is as follows: 

$ I F target_file > dependency_files THEN 

task lines 



$END 

where 

target-file is the name of the file that is constructed by the task lines. 

dependency_files are object or source files that are used to construct the target 
(e.g., via a compile or link). 

task-lines designate what processing needs to be done to bring target 

file up-to-date. 

MAKE then looks at the characteristics (such as last-modify time and date) of the 
named files and constructs a submit file with those user-specified task lines that are 
needed to generate the up-to-date version of the target file. 

Example 1 shows a complete MAKE file that states the dependency (shown in 
figure 1 - 1 ) as well as the tasks to be executed if any of the dependencies are not 
fulfilled. If the files in the dependency list are dependent on other files, those 
dependencies are also declared. 
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Example 1: 



$IF lO.LNK > READ . OBJ , WR ITE . OBJ , DATA . DBJ , UT I L . DBJ THEN 

RUN LINK86 R E A D . B J , W R I T E . B J , D A T A . D B J , U T I L . D B J TO 10. LN 
$END 

$ I F READ . OBJ > READ .SRC THEN 

RUN PLM86 READ . SRC 
SEND 

$ I F WRITE. OBJ > WR I TE . SRC THEN 

RUN PLM86 WR I TE . SRC 
$END 

$ I F DATA . OBJ > DATA .SRC THEN 

RUN PLM86 DATA .SRC 
$END 

$ I F UTI L . OBJ > UTI L . SRC THEN 

RUN PLM86 UTI L . SRC 
$END 



The first node of this file checks to see if lO.LNK is older than any of the .OBJ files. 
If it is, MAKE places the task lines into the output file. The last four dependency 
nodes compare the age of each source and corresponding object module. If the object 
module is older than the source, MAKE also places those task lines in the output file 
(submit file). 

The resulting submit file contains the task lines exactly as MAKE reads them. Since 
MAKE is dependent on the accuracy of this file, it is suggested that the PRINT 
option be issued in a MAKE invocation so that you can verify the accuracy of the 
dependency information. 

After the dependency specifications are checked for accuracy, the output file is created. 
This file is the submit file that consists of the appropriate task lines. 

If MAKE detects an error in the dependency specification, it will place a message in 
the listing file and report the number of errors in the sign-off message. The form of 
the error message is 



♦ » » E R R R nnn IN LINE ///, NEAR " ttt" : message 



where 



nnn provides the error number. 

/// provides the line number. 

ttt provides input text near where the error was detected. 

message provides an explanation of the error. 



Chapter 2 contains more detailed information about MAKE and its more complex 
commands. Of key importance are the macros that simplify the MAKE file (e.g., 
show how the four object files may be represented by a single identifier). 
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Starting with SVCS 

An SVCS data base contains all the modules that make up a software system. Normal 
operation of SVCS will be to retrieve modules (GET) and replace modules (PUT or 
RETURN). Some data base administrative commands (ADMIN) also handle the 
addition and deletion of modules to the data base. 



Invoking SVCS 

SVCS invocations are fairly lengthy, involving several (logical) options. Wherever 
possible, SVCS will prompt the user for missing options. 



GET Command 

The GET command is used to check out a module from the data base. The user can 
issue the GET command to read information from the data base (e.g., to print a 
listing or look at the change history) or to obtain write permission so that the module 
can be modified. 



GET with Permission to Read 

The optional command given here retrieves a module from the data base. There is no 
write privilege. 



SVCS GET 



f1:io.db(util) TO :f5: 



In this case, :f5:util.src is the name of the file that will receive the module copied out 
of the data base. 



GET with Permission to Modify a Module 

The optional command given here requests write permission on the unit that is to be 
retrieved from the data base. 



SVCS GET :f1:io.db(data) TO :f5:data.5rc WRITE IDCjns) <cr. > 



If the ID portion of the command is left off, SVCS will prompt the user for an identi- 
fication. The identifier is mandatory for write permission and is used by SVCS to 
identify the person modifying the module. 



PUT Command 

The PUT command enables the user to return the modified module to the data base. 



SVCS PUT:' :f1:io.db{read) FROM :f5:read.5rc IDCjns) 
HISTORY {text) <cr> 



where 
text 



provides commentary as to why the module was changed 



The user can either supply the history information in the command line or wait for 
SVCS to prompt for it. The history option is required if the PUT command is for a 
source module. 
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If you attempt to issue the PUT command without having write permission, SVCS 
will issue an error message. 



RETURN Command 

The RETURN command enables the user with write permission to return a module 
to the data base without having modified it. 



SVCS RETURN :f1:io.db (NRITE) 



SVCS Completion 

When SVCS is completed, it will sign off 

SVCS COMPLETED 

You have now learned the basic commands to modify the units with a data base 
controlled by SVCS. Chapter 3 contains more detailed information about SVCS and 
its options. 



SVCS Data Base Administration 

Since modification of the data base is controlled, it is not necessary for the average 
user to become familiar with the following section. Its purpose is to familiarize those 
particular users having data base responsibility with the administrative functions 
associated with a data base controlled by SVCS. 



ADMIN Command with CREATE Option 

The ADMIN command with the CREATE option permits an SVCS data base to be 
created. 



SVCS ADMIN I . DB CREATE 



This instruction sets up an empty data base. SVCS issues an error message if the 
named data base already exists. 



IMPORTANT 

If you want the SVCS database to be publicly shared in an NDS-II environ- 
ment, you MUST change the WORLD access rights of the database file 
named with the ADMIN command. Do this immediately after you create it; 
SVCS will automatically use the same access rights when it creates its auxil- 
iary database files. 
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ADMIN Command with ADD Option 

The ADMIN command with the ADD option allows the administrator of the data 
base to add units (modules) to the data base. These units are empty (a PUT command 
stores its initial contents). 



SVCS ADMIN 10. DB ADD (UNIT = READ, NRITE, DATA, 



This instruction adds four units (READ, WRITE, DATA, UTIL) to the data base, 
lO.DB. 



ADMIN Command with DELETE Option 

The ADMIN command with the DELETE option allows the administrator of the 
data base to delete units from the data base at any time. 



SVCS ADMIN 10. DB DELETE (UNIT = R E A D , N R I T E , D A T A ) 



This instruction deletes three units (READ, WRITE, DATA) from the data base 
lO.DB. 



ADMIN Command with ADD Option /Initialized Source 

This instruction allows the administrator of the data base to add units to the data 
base and initialize the source. 



SVCS ADMIN 10. DB ADD (UNIT = read FROM : f 5 : r e a d . 5 r c ) 



These commands are used to provide basic adminstrative functions. Chapter 4 gives 
a detaikd command description for those users with data base responsibility. 
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CHAPTER 2 
PROGRAM CONSTRUCTION (MAKE) 



This chapter presents a more in-depth presentation of MAKE. It provides you with 
more detailed information on the structure of the MAKE file and invocation controls. 



What Is MAKE? 

The MAKE program is designed to generate a submit file that can be used to construct 
the most current version of the requested software. The construction of the most 
current software is based upon the dependency of one file upon another. 

MAKE performs the following functions: 

• Parses the user-specified dependency file 

• Checks the relative ages of the specified files 

• Creates a submit file containing only the user-specified tasks necessary to 
generate a new version of software. 

MAKE begins processing the input file by checking the modification characteristics 
and interrelationships of the files you select. Generally, linked object files are depend- 
ent upon source files and a load module is dependent upon object modules. These 
dependencies can best be represented by a dependency graph (see figure 2-1). At 
each dependency node in the graph you can designate one or more tasks that need to 
be accomplished to bring the file up-to-date. These tasks are typically compiles (to 
bring the object file up-to-date with the source) and links (to bring the link or load 
module up-to-date with the object files). 



PROGRAM 
lO.LNK 



( READ.OBJ ) f WRITE.OBJ j ( DATA.OBJ J ( UTIL.OBJ J 







( ) OBJECT FILE 

C^ SOURCE FILE 



Figure 2-1. Software Development File Dependencies 
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Based upon the dependency data supplied by you and modification information in tiie 
directory, MAKE automatically specifies which tasks need to be performed to gener- 
ate the current or requested version of a program or program module. Thus, if an 
include file is used by only five of the twenty modules used to construct an entire 
program, modifications made to the include file would subsequently cause recompi- 
lation of only those five modules. This process avoids costly recompilation of software 
modules that have not been modified since the last time they were compiled and yet 
assures you that the software created is current. 



Make Structure 



MAKE translates the user specified MAKE dependency file (containing the interre- 
lationships between files and the set of tasks to be performed if the file dependencies 
are not fulfilled) into the submit file that contains only those tasks required to create 
the latest version of a program. 



Dependency File 

A dependency file consists of one or more MAKE commands. These commands are 
either macro definitions, SVCS data base access definitions, or dependency nodes. 
Each of these is explained in the following sections. 

Each section of the dependency file contains the specifications of a node in the 
dependency graph. Each node consists of the following: 

• Target — indicates the files being constructed. If more than one target is speci- 
fied, the oldest is used to compare modification attributes. 

• Dependency — indicates those files that are used for construction of the particular 
target or targets. 

• Task — the set of program invocations and commands that are to be performed 
for reconstruction of the target. 

The following rules apply to the specifications in the dependency file: 

1. A dollar sign ($) must appear as the first non-blank (or tab) character on a 
MAKE command line (as opposed to task lines). 

This character differentiates command lines (macro definitions, target/depend- 
ency specifications, SVCS access definitions, and iteration commands) from task 
lines (those lines that are passed through the submit file). Leading blanks and 
tabs may be used to format the MAKE command lines since they are ignored by 
MAKE. 

2. A semi-colon (;) that is not enclosed by quotes (" ") can appear in a MAKE 
command line, causing MAKE to ignore all characters appearing after the semi- 
colon to the end of the line. This feature can be used to include comments in the 
MAKE file. 

3. Only task lines are placed in the submit file that MAKE generates. 

4. A macro definition must appear before the macro is used. 

The target, dependency, and task information is specified as a unit in such a sequence 
that, following the specification of the target and dependency information, is a series 
of zero or more task lines. Such a unit is referred to as a dependency node. 
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A MAKE dependency file consists of up to five types of constructs described as follows: 
Dependency nodes 
Task lines 
Macro definitions 
Iteration commands 
SVCS access definitions 



Dependency Nodes 

The target/dependency specification (established at each dependency node) matches 
up a target file (or list of target files) with a file (or list of files) on which it depends. 
This specification takes the form of the keyword IF, followed by the target files, 
followed by the special character > (meaning is older than), followed by the depend- 
ency files, and then the keyword THEN. This specification is followed by zero or 
more task lines and finally, the keyword END. For example, 

$IF READ. OBJ > READ. SRC THEN <cr> 

task lines 

$ END 

If any dependency file within a dependency list has been modified more recently than 
the target file (or the oldest of the target files at this node), the tasks are required 
for updating the target and are placed in the submit file. Other circumstances that 
also cause the tasks to be placed in the submit file are as follows: 

• If the target file does not exist, it is not an error. The intent of the tasks would 
most likely be to construct the target regardless. This condition would cause the 
task lines to be added to the submit file. 

• If one or more dependency files do not exist, one of the following outcomes occur. 
If the files are targets in other dependency nodes, no error is generated, because 
those files would be created at run time by the other dependency nodes. However, 
if the files are not targets in other dependency nodes, an error is generated. 



Task Lines 

Task lines begin with any character other than a $ as the first non-blank (or tab) 
character on the line. 

These lines are not inspected except to perform macro substitution; they are token- 
ized so that the macros can be found and replaced. The lines are, however, reconsti- 
tuted if they are written to the submit file. Since these lines might then appear different 
than those in the task lines, you may wish to indicate that the lines are to remain 
exactly as they are (including spacing). This can be accomplished by placing quotes 
(either single or double) around the line. MAKE would then strip away the quotes 
and simply place the line in the submit file with no further modification and no macro 
substitution. 



Macro Definitions 

A macro is a command that represents a string of frequently used instructions. Macro 
definitions are MAKE command lines that define macros (string substitutions) to be 
used throughout the remainder of the file. You define macros to add readability to 
the MAKE file and/or to simplify the specification and modification of this file. 
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The syntax of a macro definition is as follows: 

$ S E T macro_name T macro^specification 

where 

macro^name is the name of the macro. 

macro^specification is either a substitution macro or an enumeration macro, as 
described later. 

A macro is used by naming it. The name must be preceded by the macro character 
%. In order to distinguish a macro from the surrounding context, the macro name 
can be delimited by a matching pair of cither single or double quotation marks. For 
example, 

X"SOURCEDEVICE" FILE. SRC 

references the macro named SOURCEDEVICE. 



Substitution Macros. A substitution macro defines a string of text that is to replace 
the macro reference whenever it occurs in either a MAKE command line or task line. 
A string consists of all characters contained between a set of matching double or 
single quotes. 

A string is not inspected until it becomes the alternate input at the time of substitu- 
tion (is invoked). Macro references can be nested in this way to a depth of 16 levels. 



Example 

$SET SOURCEDEVI CE TO : F 1 : 

or 

$SET OPTIONS TO 'COMPACT 0PTIMIZE(1)' DEBUG XREF 



Enumeration Macros. An enumeration macro is used to specify a list of substitution 
strings (such as filenames or fragments of filenames) that are to be referenced together 
or iterated upon. The enumeration macro is extremely helpful for handling groups of 
files that are treated in the same manner. The syntax of the enumeration macro is as 
follows: 

$ S E T identifier TO ( enumeration list) 



Example 

$SET FILES TO ( R E A D , W R I T E , D A T A , U T I L ) 



Parameter Macros. These macros are used with the parameters option to allow run 
time specification of values within the dependency specification. 
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When MAKE is invoked, actual parameters are specified through the parameters 
option. Within the dependency specification, there can be formal parameter refer- 
ences (parameter macros) of the form %n, where n is a decimal digit (0-9). When 
the dependency file is parsed, the actual parameters are substituted for the formal 
parameters in the same manner as for substitution macros. The formal parameter %n 
is then replaced by that element of the list of actual parameters specified in the 
parameter option (%0 is replaced by the first list element, etc.). If there is no actual 
parameter for the formal parameter, the replacement is performed using the null 
string. 

Specification of a MAKE dependeny file does not need to be tied to fixed device 
numbers or directory names. Instead of specifying a file as 

: F 1 : DATA .SRC 

it is far more flexible to specify it as 

XODATA . SRC 

and to suppy it with the device number or directory name when MAKE is invoked. 



Special Macros and Macro Constructors. These macros are useful for shorthand 
specification of dependency nodes (target files, dependency file, task lines). They allow 
a concise notation that is often more readable and maintainable than typing filenames 
throughout. The macro constructor %ALL is used in conjunction with an enumera- 
tion macro to specify a concatenation of all of the files specified by the list. The 
special macros %TARGET and %DEPEND are shorthand specifications for the target 
file list and the list of dependency files, respectively. References to %TARGET and 
%DEPEND can only appear in task lines. However, references to %ALL are allowed 
in target lists and dependency lists, as well as task lines. 



%ALL. %ALL can be used in a target file list, a dependency file list, or a task line, 
and is replaced by a concatenation of the enumeration macro elements (separated by 
commas). A header (the characters preceding the enumeration macro reference, e.g., 
directory name) is concatenated to the beginning of each element and the trailer (the 
characters following the enumeration macro reference, e.g., file extension) to the end 
of each element. Therefore, the same enumeration list can be used for source and 
object files' different directories. 

Using %ALL in the following example: 

$SET FILES TO ( R E A D , W R I T E , D A T A , U T I L ) 

the macro constructor %ALL(:F1:%"FILES".SRC) would be expanded as 
:F1:READ.SRC,:F1:WRITE.SRC,:F1:DATA.SRC,:F1:UTIL.SRC, while the 
constructor %ALL(%"FILES".OBJ) would be expanded as READ.OBJ, 
WRITE.OBJ,DATA.OBJ,UTIL.OBJ. 

This allows the user to maintain a file list in a single place and yet reference that list 
in several different forms. 



%TARGET. The %TARGET macro represents the target file list. It is replaced in 
the input stream by the list of target file names (separated by commas) for the 
dependency node in which it occurs. 
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%DEPEND. The %DEPEND macro represents the list of dependency files. It is 
replaced by the list of dependency filenames for the dependency node in which it 
occurs (separated by commas). It can only be used in task lines. 

Using %TARGET and %DEPEND in the standard example: 

$SET FILES TO (" READ ", "WRITE"," DATA ","UTIL") 

$ ; The root of the dependency graph 
$IF lO.LNK > XALLCX" FILES ".OBJ) THEN 

RUN LINK86 X DEPEND TO XTARGET BIND 
$END 

$FOR I IN XFILES 

$ I F X " I " . B J > X " I " . S R C THEN 

RUN PLM86 X DEPEND OPTIMIZEO) XREF 

$END 
$END 

In the above case, the first task line is treated the same as 

RUN LINK86 A. OBJ, ... 

The second task line is treated the same as 

RUN PLM86 A. SRC OPT ... 

Iteration Command 

The iteration command is useful in performing a set of MAKE commands over a 
group of files. The command takes the form of the keyword FOR, followed by the 
index macro (a name that should not be previously defined), followed by the keyword 
IN, and a reference to an enumeration macro (generally a list of filenames). 

This MAKE command and an END MAKE command line bracket a set of lines that 
will be iterated over once for each element in the enumeration macro list. These lines 
can be dependency nodes, macro definitions, or SVCS access definitions. 

Example 

Given the enumeration macro 

$SET FILES TO ( R E A D , W R I T E , D A T A , U T I L ) 

the iteration command would be 

$FOR I IN XFILES 

$ I F X M ' . OBJ > X M ' . SRC THEN 
PLM86 X M ' . SRC 

$END 
$END 

which is the same as 

$ I F READ . OBJ > READ .SRC THEN 

PLM86 READ . SRC 
$END 



2-6 



A User's Guide to Program Management Tools Program Construction (MAKE) 



$ I F UTI L . OBJ > UT I L . SRC THEN 

PLM86 UT I L . SRC 
SEND 

and the iteration command 

$FQR I IN XFILES 

$SVCS XM'.QBJ = I . DB(X I , , OBJECT) 
$END 

is the same as 

$SVCS READ. OBJ = I . D B ( R E A D , , B J E C T ) 



$SVCS UTIL.OBJ - I . DB( UT I L , , OBJECT) 

SVCS Access Definitions 

Within the dependency file is a special form of file reference called an SVCS refer- 
ence. This is a reference to a particular module and variation within a SVCS data 
base and requires four pieces of information: 

• The name of the data base file 

• The name of the module 

• The variation 

• The class of information (source, object, etc.) 

Example 

$SVCS READ. OBJ - 10. DBCREAD, .OBJECT) 

This access definition tells SVCS that all references to the file named READ. OBJ 
are really references to the object of unit READ in the data base named lO.DB. 

In this reference, all fields except the data base name are optional, since SVCS 
supports the concept of defaults. 

When an SVCS file is referenced in a target or a dependency list, the modification 
information is retrieved from the named data base where it is stored for each variant. 
In this way, modification to one variant in the data base will not affect the 
dependencies on the other variants. 

The following is the same example used for special macros and macro conductors; 
however, it includes SVCS access definitions and illustrates the use of many flavors 
of macros and the macro constructor. 

ISET FILES TO (READ, WRITE, DATA, UTIL) 

$SET VARIANT TO "V3.5" 

$FOR I IN XFILES 

$SVCS X"I".OBJ - 10. DB(XI,XVARIANT, OBJECT) 
$SVCS X"I".SRC - 10. DB(XI,XVARIANT, SOURCE) 

$END 
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; The root of the dependency graph 
$IF IQ.LNK > XALKX" FILES ".OBJ) THEN 

$ -, SVCS get of object files 

RUN LINK86 XDEPEND TO XTARGET 
$END 

IFOR I IN XFILES 

$IF X"I".OBJ > X"I".SRC THEN 

$ ; SVCS get of source file 

RUN PLM8G XDEPEND OPTIMIZEO) XREF 

$ ; SVCS put of object 
$END 
$END 

Submit File 

The submit file created by MAKE contains the tasks (as supplied by the user in the 
dependency file) necessary to bring the target up-to-date. 

Lines added to the submit file will not, in general, make any assumptions about the 
command line format. These lines will be constructd from the task lines specified by 
the user (with macros expanded). The following are additional rules concerning the 
lines in this file: 

• No line will exceed 78 characters in length (including the continuation character 
and the carriage-return and line-feed). 

• If a line is to be continued, it will end with a space followed by the character &. 
Due to expansion of macros, some lines may have to be broken up as continuation 
lines. 



MAKE Invocation 

The form of the invocation as well as the method for passing a command line to the 
program is host specific. The general invocation of MAKE is as follows: 

MAKE file_name options 



MAKE Syntax 

The general syntax for the MAKE program is presented here for reference. 

make_command ■ make_pgm command^tail . 

make_pgm » / * the O.S. dependent specification of the executable object of the program MAKE 
or MAKE.86 * I . 

command^tail ■ dependency_file C control_list ] . 

dependency— file - / * the O.S. dependent specification of the dependency file, created by the user, 

to describe the construction of his program (see Chapter 1) * / . 

control_list » {control} . 
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control ■ "TO" submit_file^name 

I attrib_option 

I " G E N A L L " / » don't check dependencies, gen everything * I 

I " P A G E L E N G T H " " ( " iength " ) " 

I " P A G E W I D T H " " ( " width " ) " 

I page_option 

I "PARAMETERS" " ( " argumenUist " ) " 

I print_option 

I "TARGET" " ( " target_name " ) " . 

attrib^option - "NOATTRIB" 

I " A T T R I B " [ " ( " attrib_string " ) " ] . 

print_option • " N D P R I N T " 

I "PRINT" [ " ( " list^file_name " ) " ] . 

page_option - "NOPAGING" 
I "PAGING" . 

submil^file_name - path__name . 

attrib_string - /• an O.S. dependent invocation of the ISIS ATTRIB program */ . 

Iist^file_name ■ path_name . 

path_name » / * an O.S. dependent file name * I . 

target— name ' / * the name of the root of the dependency tree that is to be made * I . 

argumenlL_Hst « argument " , " ... . 

length ■ / * a non-zero, unsigned integer * / . 

width - / • a non-zero, unsigned integer * I . 



MAKE Command Options 

MAKE accepts the following invocation command options. 

TO submiUilejname 

The TO clause directs MAKE to write the submit file to the named file. The form of 
the filename is object/source dependent. If the filename is omitted, the extension of 
the input filename is changed to CSD to create the submit filename. 

Example 

MAKE I Q . MKE TO I . SUB 

This clause would place the task lines into the file lO.SUB instead of lO.CSD. 

GENALL 

The GENALL (GA) option specifies that dependencies are not to be checked. If this 
option is specified, MAKE assumes that all dependencies will fail and therefore puts 
all of the user specified tasks into the submit file. This permits the user to run the 
entire generation without relying on partial generations that may exist. 
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Example 

MAKE lO.MKE GENALL 

This option would result in all of the task lines in lO.MKE being placed into the 
submit file lO.CSD (the default name) regardless of file modification characteristics. 

TARGET target name 

The TARGET (TG) option specifies the complete name of a target file that specifies 
a dependency node on one of the target lists in the dependency file. It instructs MAKE 
to use that dependency node as the root of the dependency tree. This option enables 
the user to specify that only part of the unit be created and the remainder ignored. 
The default is to use the first dependency node specified in the file as the root. 

Example 

MAKE lO.MKE T A R G E T ( R E A D . Q B J ) 

This option instructs MAKE to investigate that portion of the dependency graph 
starting with READ. OBJ as the target. In our example, READ.OBJ would limit the 
task lines to either compiling READ. SRC or no lines at all. 

PRINT/NOPRINT {list file name) 

The PRINT/NOPRINT (PR/NOPR) option specifies the placement of the listing 
file. If the optional list filename is omitted, the listing file is printed to a file with the 
same name as the input file but with the extension changed to LST. The NOPRINT 
command suppresses the generation of the listing file. NOPRINT is the default. 

Examples 

MAKE I . MKE P R I N T ( I . L S T ) 

MAKE 10. MKE PRINT 

Both options place a listing file into the file lO.LST. 

PARAMETERS 

The PARAMETERS (PAR) option matches actual parameters (specified in the 
invocation line) with formal parameters (specified in the MAKE dependency file). 

• If there are more formal than actual parameters, the remaining formal parame- 
ters have the value of the null string. 

• If there are more actual than formal parameters, the extra actual parameters are 
ignored. 

Example 

$SET FILES TO ( R E A D , W R I T E , D A T A , U T I L ) 
$IF lO.LNK > XALL(X0X*FILES'.OBJ) THEN 

RUN LINK86 XDEPEND TO X T A R G E T 
$END 
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$FOR I IN XFILES 

$ I F XOX M ' . DBJ > XOM'.SRC THEN 
RUN PLM86 X M ' . SRC X 1 

$END 
$END 

The MAKE file EXAMPL.MKE has two parameter macros: %0, which specifies a 
drive for the object files, and %1, which specifies options for the compiles. 

Invocation of MAKE to process this MAKE file would take the form 

MAKE EXAMPL.MKE P A R ( : F 1 : , * C M P A C T P T I M I Z E ( 1 ) ' ) 

which would substitute :F1: for each occurrence of %0 and COMPACT 
OPTIMIZE(l)FOR%l. 



PAGELENGTH length 

The PAGELENGTH (PL) option sets the maximum number of lines per page in the 
listing file. 

• The length specified must be an unsigned integer from 5 to 65,535. 

• If either the NOPAGING or NOPRINT option is being used, this option is 
ignored. 



PAGEWWIDTH width 

The PAGEWIDTH (PW) option sets the maximum number of bytes for a line in the 
listing file. 

• The width specified must be an unsigned integer from 60 to 255. 

• If the NOPRINT option is being used, this option is ignored. 



PAGING/NOPAGING 

The PAGING/NOPAGING (PI/NOPI) option specifies that page ejecting and page 
headers should or should not exist in the listing file at every page according to the 
PAGELENGTH command. 



ATTRIB/NOATTRIB 

The ATTRIB/NOATTRIB (AT/NOAT) option permits the user to reset the 
modification (dirty) bit for files that are in ISIS directories. The ATTRIB option 
allows the user to state the name of the program that will perform the resetting. The 
NOATTRIB option supresses the resetting of the modification bit. The default string 
is ATTRIB. 



NOTE 

This modification bit is available only on ISIS-II(W), the Winchester ISIS. 
This option is ignored for all files that reside on the Network Resource 
Manager (NRM) for systems on NDS-II. 
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MAKE FILES 

Make opens an input file, an output file, and optionally a listing file. 

Input File (MAKE File) 

The input file is the file of dependency information specified by the user on the 
command line. 

Output File (Submit File) 

The output file is always created. This file is the submit file that is built up of user- 
specified tasks. The user can direct this file to a specified file by using the TO 
command. 

Listing File 

The listing file contains a header summary, a dependency file listing, a dependency 
graph listing, and a file summary. 

• This file is not constructed unless the user requests it through the PRINT 
command. 

• Continuation lines in the listing are marked with a dash just to the left of the 
continuation text. 

• Only this file contains error messages resulting from improper specifications in 
the dependency file. 

Header Summary 

The header summary contains the name of the MAKE dependency file, the name of 
the constructed submit file and a list of the controls specified by the user. 

Dependency File Listing 

This section of the listing contains the dependency file as specified by the user. 

Dependency Graph Listing 

This section of the listing contains a representation of the dependency graph with 
levels of indention used to denote dependency. Each line, representing a target, a 
dependency, or both, have the following fields: 

• Depth — (3 digits) depth from the root (root is depth 1) 

• Separator — (2 blanks) 

• Indentation--(4 (DEPTH- 1 ) blanks) 

• Name — name of the target/dependency file at this node 

• Separator — (blank,colon, blank) only if there are attributes 

• Attributes — attributes relating to this file 

File Summary 

The file summary lists the number of lines and number of errors within the MAKE 
file. 

If MAKE detects an error in the dependency specification, a message is placed in the 
listing file. 
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Example 

•••ERROR nnn IN LINE /// " ttt" ; message 

where 

nnn provides the error number. 

/// provides the line number. 

ttt provides the input text near where the error was detected. 

message provides an explanation of the error. 

At program completion, MAKE will return the following completion code: 
if no errors were detected 
2 if errors were detected 

MAKE Error Messages 

The following is a list of error messages generated by MAKE. 
1 . ENUMERATI ON MACRO REQUIRED IN XALL EXPANSION 

2. UNEXPECTED END OF FILE ENCOUNTERED IN XALL 
EXPANSION 

3. UNEXPECTED END OF FILE ENCOUNTERED IN MACRO 
DEFINITION 

4. UNEXPECTED END OF FILE ENCOUNTERED IN FOR LOOP 

5. UNEXPECTED END OF FILE ENCOUNTERED IN TASK LINE 

6. UNEXPECTED END OF FILE ENCOUNTERED IN DEPENDENCY 
SPEC 

7. REFERENCED MACRO IS UNDECLARED 

8. SET COMMAND REQUIRES A MACRO NAME 

9. FOR STATEMENT REQUIRES AN ENUMERATION MACRO 

10. MATCHING SINGLE OR DOUBLE QUOTE NOT FOUND 

11. STRING LENGTH LIMIT IS 2B5 BYTES 

12. *T0' EXPECTED IN MACRO DEFINITION 
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13. MN' EXPECTED IN FOR STATEMENT 

H.MAKE STATEMENT NOT ALLOWED IN TASK LINES 

15. UNKNOWN MAKE COMMAND 

'16 . CONTI NUATI ON OF A MAKE COMMAND EXPECTED, FIRST 
CHAR MUST BE M' 

17. MAKE ERROR: MACRO STACK UNDERFLOW 

An error in the MAKE program occurred. Please document it and report the 
error to your Intel representative. 

18. MACRO EXPANSION SUPPORTED TO A DEPTH OF 16 

19. COMMA EXPECTED IN NAME LIST 

20. *THEN' REQUIRED IN DEPENDENCY SPECIFICATION 

21. NAME USED IN TARGET OPTION NOT FOUND, FIRST 
TARGET USED 



Fatal Command Errors 

The first fatal command error encountered causes MAKE to report the error to the 
console and halt processing. Fatal errors result from either an illegal or unknown 
option/option value in the invocation and are as follows: 

UNKNOWN OPTION 

ILLEGAL OPTION VALUE FOR OPTION: 

DEPENDENCY FILE REQUIRED AS FIRST OPTION-, 

RESPEC I F I CAT I ON OF OPTION NOT ALLOWED: 

TOO MANY ARGUMENTS IN PARAMETERS OPTION 

FATAL OBJECT/SOURCE CODE INTERFACE ERRORS 

The fatal object/source code interface errors occur from calls to the operating system 
that cannot be handled because of user error or lack of system resources. If the error 
occurs during an I/O operation, the following will be displayed: 

MAKE supervisor SYSTEM CALL ERROR 

FILE: file name 
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ERROR: object or source error message 

MAKE TERMI MATED 

If the error occurs during an non-I/O system call, the message is as above without 
the line containing the filename. 
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CHAPTER 3 

SOFTWARE VERSION 

CONTROL SYSTEM (SVCS) 



This chapter presents a more in-depth presentation of SVCS. Its purpose is to provide 
you with more detailed information on the structure of SVCS. 

What Is SVCS? 

SVCS allows you to set up a complete data base to manage software projects. SVCS 
provides the capability to track changes to program source code, maintains variations 
of the source and object code modules for a program, and controls access to these 
modules in a multi-programmer environment. Essentially, you can group related 
software modules, as well as variations of those modules, within a single data base. 

SVCS automatically retains history information on every change to a software module, 
including who made the change and when and why the change was made. It also 
allows different versions of a module to be uniquely identified. This makes SVCS 
well suited to applications that require customized software. 

SVCS structure 

SVCS maintains a data base of units that may be checked out and either modified 
or returned. An SVCS unit is a reference to a given data base and contains the 
following constructs (see figure 3-1): 

• Program units 

• Unit classes 

• Variations 



filename 



A(MODULE) 



SOURCE 
OBJECT 

CHANGE HISTORY 
COMPOSITION 
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WORK 
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Figure 3-1. Software Version Control 
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Program Units 

Program units are an expression of the granularity of the data base. They represent 
not just one piece of information (such as the text of a source module) but several 
pieces of information concerning a single piece of the program that is being 
developed. 

Developing a program requires manipulation of several different fragments of that 
program. These may include source files and their related object files, include files, 
and linked objects (e.g., complete programs, overlays, and tasks). One of these 
fragments is referred to as a unit within SVCS. A unit is not just one piece of infor- 
mation, but is all information relating to a particular fragment of the program. The 
majority of these will be module units that contain a piece of source (such as a 
module), a related object file (if one exists), change history for the unit, and 
optionally some composition information. 

In addition to the source fragments, a project will need to keep track of the linked 
objects (such as tasks, overlays, and complete programs) that are generated. Linked 
objects are stored in system units that are identical to module units but do not store 
any source. 



Module Units 

A module unit is a unit of source (either a source module or an include file). Within 
a data base there can be any number of such units; however, the best use of the data 
base would be to include only those sources that are related to form a logical subset 
of the program being developed (refer to the section on optimal use of SVCS in this 
chapter). 



System Units 

System units are the synthesis of one or more source modules created during the 
construction of a program. Each of these units is usually the linkage of the objects 
generated from the source modules by a translator or the linkage of several link files. 
The units provide the following: 

• A place to accumulate internal interface information 

• A place to permit outside interface to the modules 

• A place to store information that is useful for functional documentation of the 
modules as a group 

• A place to store generation information 

SVCS makes no distinction between system units and module units. They are treated 
in identical fashion. The distinction is made only through their usage. 



Unit Classes 

Each program unit has one to four or more classes of information associated with it. 
For a module unit, these classes would be the source module, the object module that 
results from compiling the source, the change history for the source, plus one class 
for any related information, such as a list of include files that are used by the source, 
or documentation describing either the module or the interface exported by the module. 
For a system unit, the classes would be the same (without the source class). 



3-2 



A User's Guide to Program Management Tools Software Version Control System (SVCS) 



SVCS predefines some of the characteristics of these classes, as defined below: 

• Source (SO) — This class holds the source module. It is generally present only for 
module units. 

• Object (OJ) — For a module unit, this class is the object that was generated from 
the source module by some translator. For a system unit, it is the object module 
that was generated from combining the object modules of several module units 
or several system units. 

• History (HT) — This class contains the who, what, when, and why of a source (or 
object) change and is available to the programmer. It is logged automatically 
every time a change is made to the source class of a unit. Changes to the history 
information can be made any time, not just when the source module of an object 
module is returned to the data base with a PUT command. 

• Composition (CP) — his class can be used arbitrarily by the user. It is available 
for any purpose that will help document the system. Typically, it might be used 
to contain a list of unit names that are used for the construction of a particular 
unit and/or the tasks required for construction. For a module unit, this list could 
be a list of include files to document dependencies. For a system unit, this list 
includes the names of the module units whose objects are to be linked together 
to form the system object. Generation procedures, interface specifications, or 
module documentation (as well as the MAKE file) could also be stored in this 
class. 

In summary, classes contain the information associated with a unit (module or system) 
that is being either developed or maintained. 



Variations 



The variation (variant) mechanism allows the programmer to have copies (versions) 
of the same unit that serve different developmental needs, markets, or end uses. SVCS 
supports such development by allowing these different sources to be stored as varia- 
tions on a single source, A variant represents different flavors of a system or conse- 
quent version of a module. Each variation has its own name and its own share of the 
classes. This enables all of the objects for the different variations to be stored in the 
same data base. 

The variation construct allows the programmer to have "shadow" copies of each unit 
to fulfill various requirements of development and maintenance of the program. The 
variations are called shadow copies because they do not actually take up separate 
space in the data base, but are merged together, resulting in substantial space savings. 
One history file (class) serves for all variations of a unit, as does one source file. This 
technique enables the user to spin off a new variation from an old one at any time. 

The names of the variations have no inherent meaning; thus they serve merely as a 
means of identification. The variation construct can either be used as a version track- 
ing mechanism or as a mechanism for tracking variations that are created to fulfill 
special requirements of different end products. 

For each unit, SVCS recognizes the default variant to be the current working version, 
WORK. A GET command of a source module with no variant specified will retrieve 
the WORK variant. Specifically, named variants may be retrieved, modified, and 
returned, just like the current working version. Variants are created with the ADMIN 
command and FROM existing variants. 
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Optimal Use of SVCS 

Because the SVCS data base is built upon the existing file system, it is fragmented 
into many files (depending on the number of units, classes, and variants). There will 
be at least three files per unit in the data base plus one per variant. For large projects, 
therefore, there will be many files, with potential for programmer contention 
accessing the data base. 

For this reason, it may be wise to break up a large project into more than one data 
base. There is no penalty for having more than one data base in a project, especially 
if they are broken along logical lines (nucleus, I/O system, application, or overlay 
boundaries). 

There is no physical limit to the number of units in a data base (other than those of 
the file system). However, keeping the number of units and variants under 50 or 100 
should limit the number of files (and lengthy disk access) and reduce programmer 
contention for the data base. 

It is recommended that SVCS data bases occupy entire NDS-II sub-directories, rather 
than mix user-accessible files with SVCS-accessible files. 



Major Functions of SVCS 

SVCS allows you to perform the following functions on the data base: 

• ADMIN function — allows you to create and delete units and unit variations. It 
also allows you to manipulate attributes associated with the variants. 

• GET function — allows you to retrieve a unit from the data base either to read or 
to modify. Any variant and class of information for a unit is available to the GET 
command. 

• PUT function — lets you return a unit to the data base (with WRITE permission) 
and have the unit's change history update. This allows you to get a source with 
WRITE permission, edit it, and then return it to the data base. When PUT of 
source occurs, information concerning the changes is automatically logged. At 
this time, you can also request that commentary text about the change be placed 
with the change history. 

• RETURN function — enables you to return modification permission for a source 
that was acquired from the data base with WRITE permission. This treats the 
GET and RETURN transactions as though they never occurred (no record exists 
in the change history). Both the GET and the PUT function act as intelligent 
COPYs. 



SVCS Commands 

SVCS accepts the following commands for processing. 

GET 

The GET command is used to retrieve information from the data base. 

TO file_name 

This clause names the file that is to receive the information requested in the GET 
command. It is not optional. 
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Example 

SVCS GET p gm . d b ( ma i n ) TO : f 1 : m a i n . s r c 

The options associated with a GET command (WRITE, IDENTIFIER, HISTORY, 
COMMON) are described as follows. 

WRITE [{varianUist)] 

The WRITE (WR) option requests write permission on the piece of information that 
is to be retrieved (checked out) from the data base for the purpose of modification. 

• Permission is granted if no one has it checked out and if the requester has write 
permission on the data base. 

• The optional variant list allows the requester to retrieve multiple variants at the 
same time. 

Example 

SVCS GET pgm.db(main) TO :f1:main.5rc NRITE 

IDENTIFIER 

The identifier (ID) clause is used to designate the person requesting the information 
from the data base. It is required for WRITE permission. 

• If the ID is omitted on a GET command for WRITE permission, SVCS prompts 
for it with ID:. The ID is used to identify who has the module. 

• The ID entered in response to the above prompt will consist of all the characters 
between the prompt and the carriage return. 

Example 

SVCS GET pgm.db(main) TO :f1:main.3rc WRITE ID (Sheila) 

HISTORY 

In a GET command, the HISTORY (HT) option annotates the source code with the 
information from the change history file. 

• In a GET command, HT is valid only for the source class and only for read 
permission so that your source file cannot be corrupted with history information. 

• It allows the programmer to find out when, why, and by whom changes were 
made to the source code. 

Example 

SVCS GET pgm . db(main) TO :f1:main.3rc HISTORY 

COMMON 

The COMMON (CM) option directs SVCS to add lines to the retrieved source code 
to delineate any lines that are common to all of the variants listed in the WRITE 
option variant list and the variants requested by the GET command. 

• It is valid only for the source class. 



3-5 



Software Version Control System (SVCS) A User's Guide to Program Management Tools 



Example 



SVCS GET pgm.db(main) TO :f1:main.5rc & 
WRITE (x119,v1.2) ID (user) COMMON 



PUT 

The PUT command enables you to return information to the data base that was 
checked out for WRITE permission. 

• The PUT command is not valid if the requester did not check it out with WRITE 
permission (verified through ID comparison). 

• When the PUT command fails, it is ignored. 

The options associated with a PUT command (FROM, WRITE, IDENTIFIER, 
HISTORY) are described as follows: 

FROM file-name 

The FROM clause places the named file into the data base. 

• It is not valid if the piece of information specified is not checked out by the 
person designated by the ID option. 

Example 

SVCS PUT pgm . db ( ma i n ) FROM :f1:main.5rc 

This command causes SVCS prompt for the ID and the history information as 
explained below. 

WRITE [{varianUist)] 

The WRITE (WR) option is used as a counter-check for the GET command. 

• If the variant list is not the same as specified in the GET command, the PUT 
command fails. 

• In general, the user will not choose to use this command but rather rely on the 
default. The default is to use the list specified on the GET command. 

Example 

SVCS PUT pgm.db(main) FROM : f 1 : m a i n . s r c WRITE CX119,V1.2) 

IDENTIFIER 

The identifier (ID) option is used to designate the person replacing the information 
into the data base. 

• The options is used to verify that the person replacing the information in a PUT 
command is the same person who checked it out. 

• If the ID is not provided, SVCS prompts with ID:. The ID entered consists of all 
the characters between the prompt and the carriage return. 

• If the PUT command is used for the source class, the ID is logged with the date, 
time, and optional data supplied by the user with the HISTORY option. 
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Example 

SVCS PUT pgm . db ( ma i Ti ) FROM : f 1 : m a i n . 5 r c ID (Andy) 

HISTORY 

The HISTORY (HT) option allows the user to supply information about why the 
file was modified. 

• It is terminated by the first non-quoted right parenthesis encountered. 

• The user-supplied information can be retrieved by either doing a GET command 
of the history class associated with a unit or by using the HISTORY option on a 
GET of the source class for a module unit. 

• If the HISTORY option is omitted from a PUT command on a source class, 
SVCS prompts for it with the prompt HISTORY:. This prompt is displayed at 
the beginning of each line until a zero-length line is encountered (a line contain- 
ing only a carriage return/line-feed). 

RETURN 

The RETURN (RT) command returns write permission for the designated variants. 
This command is used if the programmer gets a file and then decides not to modify 
it. As with the PUT command, the ID option is required and the WRITE option can 
be specified. If the Vv'RITE option is used, the variant list must match what was 
specified in the GET command. 

Example 

SVCS RETURN p g m . d b ( m a i n ) ID (Stu) 

ADMIN 

The ADMIN command allows SVCS to perform the various administrative functions 
required for maintaining a data base. 

The options associated with ADMIN (CREATE, ADD, DELETE, 
WRITEACCESS, DEFAULTACCESS, PRINT) are described as follows. 

CREATE 

The CREATE (CA) option permits the administrator of the data base to create a 
dat base. If the file given as the data base name already exists, it is an error. SVCS 
will then prompt, asking whether to overwrite the existing file or to simply abort. If 
the named data base already exists, it is overwritten. Note that after creating a 
database that is to be shared, be sure to change its world access rights so that others 
may modify it. 

Example 

SVCS ADMIN pgm.db CREATE 

ADD and DELETE 

The ADD option permits the administrator of the data base to add either units or 
variants to the data base at any time. Units added will automatically have all variants 
defined for that data base. 
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Example 

SVCS ADMIN pgm.db ADD ( V A R I A N T - p r o j A , p r o j x , p r o j 1 ) 

SVCS ADMIN pgm.db ADD ( U N I T - m a i n , d a t a , i n i t ) 

This example adds three units (main, data and init) to the data base. 

The DELETE (DL) option allows the administrator to delete units and variants from 
the data base at any time. 

Example 

SVCS ADMIN pgm.db DELETE ( V A R I A N T - p r o j B ) 

Both the ADD and DELETE options allow the administrator to specify the creation 
or deletion of one or more units (module and system) and one or more variants. 

• UNIT. A unit can either be created in the data base as empty (if the FROM 
clause is not used) or with the source class file initialized to the contents of a 
named file (if the FROM clause is used). It is created with an empty object class 
file, a variant with the name WORK, and a history class file with an entry for 
the creation. It has both read and write permission. 

Example 

SVCS ADMIN pgm.db ADD (UNIT - main FROM :f1:main.5rc 

This command adds the unit main while initializing it to the contents of the file 
:fl:main.src. 

NOTE 

The FROM clause initializes the WORK variant of the unit. All other 
variants of the unit remain uninitialized. Thus the user should define units 
before defining variants. 

• VARIANT. When a variant is either created or deleted, the action occurs on the 
entire data base. A variant is always created from an existing variant and has 
the identical contents of that variant. In creation, the variant is stated in the 
FROM clause. If not, it is created from the WORK variant. The variant is created 
with write access enabled but with no associated default accesses. 

WRITEACCESS 

The WRITEACCESS ( WA) option allows the administrator of the data base to allow 
or disallow writing to a specified variant within the data base. Any GET command 
requesting permission to write on a variant where write access is disallowed will fail. 

Example 

SVCS ADMIN pgm.db ADD(VARIANT - x119 FROM WORK) & 
NR ITEACCESS (x119-FALSE) 

The preceding example shows that the administrator wishes to create a prototype 
variant xll9 from the WORK variant with write access disallowed. By disallowing 
write access, the owner of the data base has rendered the variant unmodifiable. 
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DEFAULTACCESS 

The DEFAULTACCESS (DA) option allows the administrator of the data base to 
set up default accesses to any variant in the data base. 

If the ID list is not specified, the specified variant becomes the default for all 
identifiers that are not in any other variant default list. 

The word NONE eliminates all identifiers from the list for that variant. 

The word ALL causes the specified variant to become the default for all identi- 
fiers. This global default can be modified for individual users through further 
DEFAULTACCESS definitions. 

Identifiers in the ID list are stored with the variant in the data base file. 

An identifier will never appear on the default list of more than one variant of a 
unit because if it is added to one list while on another, it is automatically deleted 
from the old list. 

Example 

SVCS ADMI pgm.db DEFAULTACCESS (x119-ALL) & 

DEFAULTACCESS (WORK-CHRIS, ELSA, MATT, ERIC) 

This command would direct all accesses to the data base in which the variant was 
not named to the variant named xll9. The exception is that the default variant for 
the four named programmers would be the one named WORK. In this way, all outside 
references to the data base (generally from groups requiring prototypes) can be 
directed without the outside groups needing to know specifics. At the same time, it 
permits the programmers working on the program to use the default. 

PRINT 

The PRINT (PRI) option provides the user with a formatted directory of the data 
base. 

Example 

SVCS ADMIN pgm.db PRINT (db.lst) 

SVCS Command Options 

The following options can be applied to any of the SVCS commands. 

PROMPT/NOPROMPT 

The PROMPT/NOPROMPT (PRO/NPRO) option tells SVCS whether to prompt 
on certain error conditions or simply issue the error message and exit. The default 
for this command is PROMPT. 

TIMEOUT/NOTIMEOUT 

The TIMEOUT/NOTIMEOUT option establishes the defined period of time SVCS 
will try to gain control of the data base before giving up and exiting to the command 
level. Since more than one person may wish to access the data base at any time, 
SVCS will pause and try again if another SVCS command is executing. 
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• The default time is 300 seconds. 

• TIMEOUT can override this default with a user-specified number of seconds. 

• NOTIMEOUT instructs SVCS to wait forever. 

Example 

TIMEOUT (30) 

SVCS Invocation 

The form of the invocation, as well as the method for passing a command line to the 
program, is host specific. The general form of invocation is as follows: 



SVCS 



GET 
PUT 

RETURN 
ADMI N 



data_base_spec options 



SVCS Syntax 

The general syntax for the SVCS program is presented here for reference. 

S V C S_comma/7c( ■ S \f C S _pgm command_tail . 

SVC S_pgm = / * the O.S. dependent specification of the executable object of the 
program SVCS.86 * I . 

command_tail - command_type I common_options ] . 

command_type ■ "GET" db^spec G E T_options 

I "PUT" db_spec PUT _options 

I "RETURN" db_spec R E T U R N _opf/ons 

I "ADMIN" db_spec ADMI W_options . 

db^spec ■ db_name [ " i " I uniL.name] [ "," [variant] 

i "," [class] ] ] ")" . 

db_name ■ file__name . 

unil^name ■ identifier . 

variant ■ identifier . 

class - "SOURCE" 

I "OBJECT" 

I "HISTORY" 

I "COMPOSITION" . 

G E J_options ■ G E 1 _option ... . 

G E J_option ' "TO" filename 

I "WRITE" [ " ( " variant_list " ) " ] 

I "ID" " ( " identifer " ) " 

I "HISTORY" 

I "COMMON" . 
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P U J_options ' P U T_option ... . 

P\i T_option ' "FROM" filename 

I "WRITE" [ " ( " variant^list " ) " ] 

I "ID" " ( " identifer " ) " 

I "HISTORY" " ( " history_string " ) " . 

RET \}RH_options = R E T U R N_opf/on ... . 

RETURN_opf/on « "WRITE" [ "(" varianL.list ")" ] 
I "ID" " ( " identifier " ) " . 

A D M I W_options = A D M I f\_option ... . 

ADM I N_opf/on « "CREATE" 

I "ADD" " ( " addUtem " ) " 

I "DELETE" " ( " deleteUtem " ) " 

I "PRINT" " ( " list_file_name " ) " 

I access_optlons . 

addUtem - "UNIT" " - " add_unit_list 

I "VARIANT • variant [ "FROM" variant 1 . 

deleteUtem - "UNIT unil^list 

I "VARIANT variant_list . 



II II 



unilL_list ■ unit— name 

add_unit^list » add^unit " , " ... . 

add^unit - unit_name [ "FROM" file_name I . 

access_options ■ " W R I T E A C C E S S " " ( " variant_assign " ) " 

I " D E F A U L T A C C E S S " " ( " variant i id_spec I " ) " 

id_spec ■ "ALL" 
I "NONE" 
I idUist . 

variant^assign ■ variant-list "»" boolean . 

variant_list » variant " , " ... . 

/?oo/eaA7 - "TRUE" 
I "FALSE" 

id__list ■ identifier " , " ... . 

file_name ■ /* O.S. dependent file name */ . 

identifier ' / * an argument as defined by [2] * / . 

common_options ■ P R M P l_option 

I T I M E U T .^option . 

P R M P T_opf/OA7 - "PROMPT" 

I "NOPROMPT" . 
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T I M E U J_.option - "TIMEOUT" " ( " num_seconds " ) " 
I "NDTIMEOUT" . 

num_seconds ■ / * number of seconds to wait before timing out * I . 



SVCS Files 

SVCS opens a number of different files depending on the options specified by the 
user. The various files are described as follows. 



Data Base File 

The data base file is the heart of SVCS. It contains all of the information about the 
various units, variants, classes, and access rights within the overall data base. 

This file is generally centrally controlled during a software development process. Any 
user can request permission to read the information within the file; however, if the 
user wants to modify the data, he must have write access (as designated by the host 
operating system). For write requests, the data base file acts as a lock, allowing only 
one write request to be honored at any one time. However, once that request has 
control of the data base file, the user can open any of the other files seeking write 
permission without fear or deadlock. 

If the request to get control of the data base file fails because someone else is either 
reading from or writing to that file, SVCS will wait a short time (approximately one 
second) and then retry the request. SVCS will wait until that control is relinquished. 
The amount of time that SVCS will wait for the data base can be controlled by the 
TIMEOUT option as discussed in the summary of SVCS commands contained in 
this chapter. 



Auxiliary Files 

The SVCS data base is not constructed as one large file but as a central data base 
file that references several auxiliary files. These files contain information that is 
specific to each unit. They have the same name as the data base file but with the 
extension changed. The extension on these files is three characters long with one of 
the characters being a decimal digit (0-9) and the remaining two being upper case 
alphabetic. The extensions are allocated as needed and never reused. This allows for 
archiving, deleting, and then restoring from the archives. 



Retrieved Files 

Either a retrieved object or history file results in a straight copy of the auxiliary file 
to the file specified in the TO command. These files are never encoded by SVCS. 

A retrieved source class file or composition class (both are stored in an encoded 
format) is decoded and then placed into the file specified by the user. For source, the 
user is also able to specify either or both of two options (HISTORY and COMMON) 
that will affect what is placed in the output file. The results of these options are 
discussed in the following paragraphs. 
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History Option 

If the history option is specified on a GET command, the history file is written to the 
output file preceding the source file lines. It looks like a listing, which is why it cannot 
be changed. Each line of the source file is preceded by a five-character change number 
(representing the change that created that line and referencing one of the entries in 
the change history) followed by a blank. 

Example 

« 1 07/ 1 4//82 

VAR I ANTS : 

TEXT : INITIAL IZED 

# 2 7/30/82 CHRIS 

VAR I ANTS : WORK 

TEXT: This change reflects corrections to the 

third, fourth, and fifth lines. 

1 This example shows the result of using the 

1 HISTORY option on a GET of source. The 

2 first, second, and sixth lines show up as 

2 the original lines (from when the file was 
2 initialized). The other lines were changed 
1 at a later time to correct errors. 

Common Option 

If the common option is specified on a GET command (valid only on a source class), 
lines that are common to all variants in the variant list are preceded by the line shown 
in the example. 

Example 

SVCS allows the user to GET more than 

one variant at the same time. The 
$SVCS COMMON 

COMMON option can be used on such a 

GET to delineate the lines that are 

common to all variants. This example 
$SVCS END COMMON 

shows the result of just such a GET. 

The third, fourth, and fifth lines are 

common to all variants of the GET. The 

other lines only exist in the main 

variant of the GET. 



Stored Files 

A stored object or history file results in a straight copy to the auxiliary file from the 
file specified in the FROM clause. These files are never encoded by SVCS. 

A stored source class file or composition class file is compared against the lines in 
the associated auxiliary file and merged in with those lines in an encoded format to 
save space. 
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If the file being stored was retrieved with the COMMON option, the lines inserted 
to designate the common source are stripped out before the store actually takes place. 

SVCS Error Messages 

This section lists all the possible error messages associated with the SVCS program. 

Command Errors 

Command errors result from either an illegal or unknown option/option value in the 
invocation line. SVCS prompts for respecification of the erroneous information if the 
prompt option is in effect; otherwise, it merely displays the error message and exits. 
There are messages that indicate internal errors; when one of these appears contact 
your Intel representative. 

The SVSC command error messages are as follows: 

1 . DATA BASE FILE REQUIRED 

2. FILE IS NOT AN SVCS DATA BASE FILE: file_name 

3. UNKNOWN VARIANT NAME: variant 

4. CANNOT DELETE THE WORK VARIANT 

5. CANNOT CREATE, UNIT ALREADY EXISTS: unit.name 

6. CANNOT CREATE, VARIANT ALREADY EXISTS: variant_name 

7. Only 16 VARIANTS may be added in one ADMIN. 
Please break up the SVCS invocation into several 
invocations. 

8. ADMIN not interactive, please respecify with 
complete command 

9. UNKNOWN VARIANT IN WRITE LIST varlant_name 

10. FILE NOT CURRENTLY CHECKED OUT 

11. CANNOT RETURN WRITE PERMISSION, OWNER IS owner_name 

12. CANNOT PUT FILE, OWNER IS owner_name 

13. WRITE ACCESS NOT ALLOWED ON VARIANT: variant_name 
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14. Duplicate occurence of variant : variant_name 
Occurrence in WRITE listing ignored. 



1 5 . SVCS I NTERNAL ERROR #1 

Please contact your Intel representative 

16. SVCS DIRECTORY EXTENSIONS EXHAUSTED 
Please contact your Intel representative 

17. ILLEGAL OPTION VALUE FOR OPTION: option_name 

18. UNKNOWN UNIT NAME: unit_name 

19. ID OPTION REQUIRED 

20. CANNOT PUT FILE, IT IS NOT CHECKED OUT 

2 1 . H I STORY OPTION REQUIRED 

22 . SVCS I NTERNAL ERROR #2 

Please contact your Intel representative 

23. UNKNOWN OPTION: option_name 

24. INSUFFICIENT ROOM FOR LARGEST RECORD 

25. INSUFFICIENT ROOM TO SYNCHRONIZE 

26. REQUESTED FILE IS CHECKED OUT TO: id_name 



Fatal Object /Source Interface Errors 

These errors occur from calls to the operating system that cannot be handled because 
of user error or lack of system resources. If the error occurs during an I/O operation, 
the error message is as follows: 

SVCS supervisor I/O ERROR 
FILE: file-name 
ERROR: message 
SVCS TERMI NATED 

If the error occurs during a non-I/O system call, the message will the same as the 
preceding one without the line containing the filename. 
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SVCS Prompt Messages 

If the PROMPT option is in effect, certain error conditions cause SVCS to prompt 
the user for correct input. The following prompt messages are supported by SVCS: 

A data base name is required, please enter one. 
DATA BASE : 

An SVCS command is required. The command choices are: 
GET - to retrieve information from SVCS 
PUT - to put information into SVCS 
RETURN - to return WRITE permission 
ADMIN - to perform administrative functions on SVCS 

Please enter one of these commands: 

Unknown variant (variant$name), please respecify 
VARIANT: 

An identifier is required for this operation. Please enter 
your id 
ID : 

Please specify the name of the file that is to be copied to 
"TO" FILE NAME: 

A unit name is required for this operation. 

Please specify one 

UNIT: 

Please specify the name of the file that is to be copied 

from 

"FROM" FILE NAME: 

An explanation of this PUT is required for the modification 

history. 

Please type in an appropriate entry 

H I STORY : 
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COMMANDS AND PROMPTS 



Table A-1. Summary of MAKE Commands 



Command 


Explanation 


TO 


Directs the writing of the submit file 


GENALL (GA) 


Specifies that dependencies are not to be checked and 
that everything is to be generated 


TARGET (TG) 


Specifies the target file specified in a target list (results 
in a partial generation) 


PRINT (PR) 


Specifies placement of listing file 


NOPRINT (NOPR) 


Suppresses generation of the listing file 


PARAMETERS (PAR) 


Matches actual parameters with formal 


PAGELENGTH (PL) 


Sets the number of lines per page for the listing file 


PAGEWIDTH (PW) 


Sets the maximum number of bytes for a line in the 
listing file 


PAGING/NOPAGING 
(PI/NOPI) 


Controls page ejecting and headers in the listing file 


ATTRIB/NOATTRIB 
(AT/NOAT) 


Permits the user to reset the modification bit of files in 
the ISIS directory 



Table A-2. Summary of SVCS Commands 


Command 


Explanation 


GET 


Retrieves information from the data base 


TO 


Names the file that is to receive the information 


WRITE (WR) 


Requests write permission on information 


IDENTIFIER (ID) 


Designates person requesting information 


HISTORY (HT) 


Includes history information in the retrieved file 


COMMON (CM) 


Allows for manipulation of common information 


PUT 


Returns information (checked out with write permission) 
to the data base 


FROM 


Name of file to be copied into the data base 


WRITE (WR) 


Countercheck for GET command 


IDENTIFIER (ID) 


Verifies that the person replacing the information is the 
same person who checked it out 


HISTORY (HT) 


Designates why changes were made 


RETURN (RT) 


Returns write permission for the designated variant 


WRITE (WR) 


Same as for PUT 


IDENTIFIER (ID) 


Same as for PUT 


ADMIN 


Allows for the administrative functions associated with a 
data base 


CREATE (CA) 


Creates a data base 


ADD 


Permits the adminstrator to add units or variants to the 
data base 


DELETE 


Permits the adminstrator to delete units or variants from 
the data base 
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Table A-2. Summary of SVCS Commands (Cont'd.) 



Command 


Explanation 


WRITEACCESS (WA) 
DEFAULT ACCESS (DA) 
PRINT (PRI) 


Allows the administrator to allow/disallow writeaccess to 
a given variant 

Allows the administrator to establish default access to 
any variant 

Provides formatted directory of the data base 


These options apply to the GET, PUT, RETURN and ADMIN commands 


PROMPT (PRO) 
NOPROMPT (NPRO) 

TIMEOUT 
NOTIMEOUT 


Instructs SVCS as to whether to prompt or simply exit 
on error conditions 

Establishes time period SVCS will try to gain control of 
data base before giving up 

Instructs SVCS to attempt to gain control without giving 
up 



Table A-3. Summary of SVCS Prompt Messages 



Prompt 


Explanation 


PLEASE ENTER ONE OF THESE 


SVCS command missing 


GET 


Retrieve information 


PUT 


Put information into SVCS 


RETURN 


Return write permission 


ADMIN 


Perform adminstrative functions on SVCS 


DATA BASE: 


Data base name either missing or incorrect 


UNIT: 


Unit name missing or incorrect 


VARIANT: 


Variant name missing or incorrect 


TO FILENAME: 


Filename where information is to be copied is 
missing 


FROM FILENAME: 


Filename that contains information to be put into 
the data base is missing 


ID: 


Identification of user is required 


HISTORY: 


Explanation of change is required 
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APPENDIX B 
ADDITIONAL INFORMATION 
FOR THE SERIES III USER 



This appendix contains information specific to the Intellec Series III Microcomputer 
Development System. It covers the following subjects: 

• Series III literature 

• Hardware and software required 

• System resources used by PMTs 

• System-specific examples of invocation lines and commands 

Series III Literature 

Information describing the general operation of the Series III is provided in the 
following manuals: 

• Intellec Series III Microcomputer Development Product Overview, 121575 

• Intellec Series III Microcomputer Development System Console Operating 
Instructions, 121609 

• Intellec Series III Microcomputer System Programme' s Reference Manual, 
121618 



Hardware and Software Required 

To run the PMTs, the following hardware and software are required: 

• Intellec Series III development system (with RUN version 1.5 or later) 

• ISIS-II Operating System (version 4.1 or later) 
8086-based Utilities 



System Resources 

The amount of memory available depends upon the amount of memory in your system. 
The Series III can be expanded up to one megabyte of memory addressable by the 
8086. PMTs require approximately 96K bytes. More memory must be added to 
accommodate additional workspace and programs. 



Invocation Line 

To invoke PMTs in the 8086 execution environment of the Series III, preface the 
invocation line with the RUN command. The ISIS-II operating system prompt is a 
hyphen ( - ). 

The general format of the MAKE invocation is 



RUN MAKE 



MAKE signs on with the following message: 
Seriea-III MAKE,Vx.y 
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The general format of the SVCS invocation is 



RUN SVCS 



SVCS signs on with the following message: 

Series-Ill Software Version Control System, V x.y 
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